---
title: ZITADEL Applications
sidebar_label: Applications
---

import ThemedImage from "@theme/ThemedImage";

import AuthType from "../../integrate/application/_auth-type.mdx";
import ReviewConfig from "../../integrate/application/_review-config.mdx";
import AppType from "./_application-types.mdx";

## What is an application?

Applications are the entry point to your project.
Users either login into one of your clients and interact with them directly or use one of your APIs.
All applications share the roles and authorizations of their project.

To access your applications, navigate to your project and select your application.

<img
  alt="Granted project"
  src="/docs/img/guides/console/applications.png"
  width="750px"
/>

<!-- TODO: oidc vs saml --->

## Create application

To add an application to your project, click on the add button and select your application type.

<img
  alt="Add application"
  src="/docs/img/guides/console/addapplication.png"
  width="120px"
/>

## Application Types

At the moment ZITADEL offers five client types:

<AppType />

The first three options (Web, Native and User Agent) require user interaction, the fourth option (API) has no direct user-interaction.
Depending on the app type, there are small differences in the possible settings.

To get a good understanding about user profiles and recommended flows, read the following [guide](../../integrate/login/oidc/oauth-recommended-flows.md#different-client-profiles).

### Web

Web applications are **server side rendered** applications users interact with. For example if you develop an application using Thymeleaf in Java or Razor in .NET or want to enable SSO in Gitlab.

Typical **React or Angular** apps **are not** a Web applications in this case.
A **NextJS** on the contrary would be because it allows you to implement server side code.

Following authentication types can be used:

<AuthType appType="web" />

### Native

Native Applications installed on a thin client. For example on a smartphone or computer. This can for example be Android and iOS Applications.

These applications uses the Key file generated by ZITADEL to authenticate.

<AuthType appType="native" />

### User Agent

User Agent Applications that are executed in a web browser, for example single page applications executed in the browser developed with JavaScript frameworks like [Angular](../../../examples/login/angular) or [React](../../../examples/login/react)

Following **authentication methods** can be used:

<AuthType appType="user-agent" />

### API

These are Applications without human interaction. These applications are accessed by other applications, so called machine to machine communication.

Following authentication types can be used:

<AuthType appType="api" />

After selecting your Apps Type and Authentication Method, you may need to specify redirect URIs.

### SAML

If your application doesn't support the OIDC standard, but SAML this is the right application type to choose. SAML is an open standard used for authentication based on XML.

After entering a name and choosing the application type "SAML", you will get to the SAML configuration screen.

You can either add a link to a SAML metadata file or upload it directly.
SAML metadata is an XML document which contains information necessary for interaction with SAML-enabled identity or service providers.

You can find some example configurations for SAML 2.0 in our [integrate services](/docs/guides/integrate/services) guides

## Redirect URIs

App Types with User interaction (Web, Native and User Agent) require redirect URIs.
Those redirects URIs are used to redirect the user back to your application on successful login.

These URIs are defined in your application code and are checked by ZITADEL if they correspond to your applications configuration.
Redirect URIs are checked during the login process.
Native applications can use a different protocol than http or https in order to redirect your user.

<img
  alt="Redirect URIs"
  src="/docs/img/guides/console/redirecturis.png"
  width="600px"
/>

### Development mode

In order to develop locally, or you want to redirect users to any other protocol than https://, you must enable **Development mode**.
When disabled only https is allowed, as ZITADEL's configuration is secure by default.

<img
  alt="Development mode"
  src="/docs/img/guides/console/developmentmode.png"
  width="600px"
/>

Development mode also allows glob patterns in redirect URIs with the following special terms in the patterns:

| Special Terms | Meaning                                                                                                    |
| ------------- | ---------------------------------------------------------------------------------------------------------- |
| `*`           | matches any sequence of non-path-separators                                                                |
| `/**/`        | matches zero or more directories                                                                           |
| `?`           | matches any single non-path-separator character                                                            |
| `[class]`     | matches any single non-path-separator character against a class of characters [see "character classes"][1] |
| `{alt1,...}`  | matches a sequence of characters if one of the comma-separated alternatives matches                        |

[1]: https://github.com/bmatcuk/doublestar?tab=readme-ov-file#character-classes

Special character can be escaped with a backslash (`\`).

Double stars (`**`) should appear surrounded by a path separators such as `/**/`.
A mid-pattern double star (`**`) behaves like bash's glob star option: a pattern
such as `path/to/**.txt` would return the same results as `path/to/*.txt`. The
pattern you're looking for is `path/to/**/*.txt`.

*Source: [github.com/bmatcuk/doublestar](https://github.com/bmatcuk/doublestar?tab=readme-ov-file#patterns)*

> When IPv6 URIs are used as redirects in development mode, square brackets must be escaped as they are also Special Terms for globs. `http://\[::1\]:80`

## Review Configuration

<ReviewConfig authType="code" />

## Application settings

After creating the application, you can still change its configuration if you for example need a offline_access support (Refresh token).
You can easily change your authentication method via the colored toggle on top or directly change configuration via the input and dropdown fields.

> Note: Changing application type is not possible. In this case you have to create a new application.

<img
  alt="Redirect URIs"
  src="/docs/img/guides/console/application.png"
  width="800px"
/>

On the top of the page you can check if your application is OIDC compliant.
Tasks for completion are shown in the field.

<img
  alt="OIDC Compliance"
  src="/docs/img/guides/console/oidc-compliance.png"
  width="600px"
/>

### Token settings

In the token settings you can change the type from **Bearer Token** to **JWT**, and check some settings whether you need user roles and user information in the ID Token or not.
On the bottom you can optionally set a **ClockSkew** time which is added to the expiration time of the issued token.

<img
  alt="Token settings"
  src="/docs/img/guides/console/app-token-settings.png"
  width="600px"
/>

### Redirect settings

Like on creation, you can modify you redirect settings here.
Note that for local development you most likely have to enable development mode, as redirects to http:// are otherwise blocked.
On Native Apps you can also skip the Login Success Page.

<img
  alt="Redirect URIs"
  src="/docs/img/guides/console/redirect-uris.png"
  width="500px"
/>

### Additional origins

If you need to allow additional origins which should **NOT** be used as redirect you can specify them in the **Additional origins** section.

<img
  alt="Additional origins"
  src="/docs/img/guides/console/additional-origins.png"
  width="500px"
/>
